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REMARKS 

These remarks are responsive to the Office Action, mailed February 17, 2009. Currently 
claims 1,3-17, 19-26 are pending with claims 1, 7, and 17 being independent. Claims 2 and 18 
have been previously cancelled. Claim 17 has been amended to correct a typographical error in 
response to the Examiner's objection (see, Office Action, page 2). No new matter has been 
added. 

35U.S.C. 103 

In the February 17, 2009 Office Action, the Examiner rejected claims 1, 3-6, 17, and 19- 
25 under 35 U.S.C. 103(a) as being unpatentable in view of various combinations of U.S. Patent 
No. 5,778,395 to Whiting et al. (hereinafter, "Whiting"), U.S. Patent Publication No. 
2003/0131278 to Fujibayashi (hereinafter, "Fujibayashi"), U.S. Patent No. 6,560,615 to Zayas et 
al. (hereinafter, "Zayas"), U.S. Patent Publication No. 2003/0070001 to Belknap et al. 
(hereinafter, "Belknap"), and "Efficient Distributed Backup with Delta Compression" to Burns et 
al. (hereinafter, "Burns"). 

In the Office Action, the Examiner stated that Whiting discloses all elements of the 
claims except that it "does not explicitly teach two or more repositories are configured to store a 
replica of a file, wherein a storage location and a number of replicas in each repository can be 
configured to change over time." The Examiner stated that Fujibayashi discloses this element. 
(Office Action, page 3). The Examiner further stated that Whiting does not teach "and further 
configured to capture a snapshot of a set of the shares of data at a particular point in time and to 
maintain a list of modified and/or created files since a last snapshot occurred." Id. The Examiner 
stated that Zayas discloses this element. The Examiner further stated that it would have been 
obvious to one of ordinary skill in the art at the time the invention was made to have modified 
Whiting et al. "by the teachings of Fujibayashi, since Fujibayashi teaches 'by locating data 
backups remotely, a customer can survive a disaster by restoring data using backed up data 
mirrored in a remote location that was unaffected by the disaster' (see paragraph [0002])" and 
"by the teaching of Zayas et al., since Zayas et al. teaches 'insertion and removal of entries in the 
MFL are performed by the storage system. When the first of a file's data and metadata bits are 
turned on, the storage system adds the file to the MFL. In this way a file is added only once to 
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the MFL' (see 7:40-45)". (Office Action, page 4). Applicants respectfully disagree and traverse 
these rejections. 

Claim 1 recites, inter alia, a data protection system including a fileserver configured to 
contain shares of data and to be connected with a repository, wherein two or more repositories 
are configured to store a replica of a file, wherein a storage location and a number of replicas in 
each repository can be configured to change over time; the fileserver includes: a filter driver 
operative to intercept input or output activity initiated by client file requests and further 
configured to capture a snapshot of a set of the shares of data at a particular point in time and to 
maintain a list of modified and/or created files since a last snapshot occurred; a file system in 
communication with the filter driver and operative to store client files; the filter driver is 
configured to capture the snapshot at a specified time interval based on a backup frequency 
defined in a protection policy stored in the fileserver, wherein the protection policy is configured 
to be uniquely defined for each share of data on the fileserver. 

In response to the Examiner's rejection, Applicants reiterate and incorporate herein by 
reference Applicants' arguments submitted on February 6, 2008 and on November 21, 2008. In 
addition to the previously submitted arguments, Applicants respectfully traverse Examiner's 
rejections as follows. 

As understood by Applicants, Whiting relates to a system for backing up files from disk 
volumes on multiple nodes of a computer network to a common random-access back storage 
means. (Whiting, Abstract). As previously stated by Applicants and admitted by the Examiner 
(Office Action, page 3), Whiting fails to disclose two or more repositories configured to store a 
replica of a file, wherein a storage location and a umber of replicas in each repository can be 
configured to change over time, as recited in claim 1 . This is because Whiting's files are backed 
up from disk volumes on multiple nodes of a computer network to a common random-access 
backup storage means , typically a disk volume. (Whiting, Col. 5, lines 3-6). (emphasis 
supplied). Hence, Whiting performs its backup operations to a single location only and is not 
equipped to store multiple replicas of a file , which is contrary to the present invention, (emphasis 
supplied). Whiting teaches away from storing duplicate copies of a file and instead, stores only a 
single copy of a file. (Whiting, Col. 5, lines 8-11). (emphasis supplied). In contrast, two or more 
repositories store a replica of a file, as recited in claim 1. (emphasis supplied). Further, Whiting 
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backs up its data to the same location over time, i.e., its \BACKUP\USERS location (Whiting, 
Col. 7, lines 8-19). Since Whiting is not capable of storing multiple replicas of files in different 
locations, it fails to disclose that the number of replicas stored in each repository can be 
configured to change over time as well, as recited in claim 1 . Instead, Whiting backups a single 
file to a single location (i.e., Whiting's common random access backup storage means). 

Additionally, it appears that in Whiting clients have their data replicated to a single local 
fileserver, which is the destination of date. Whereas, an advantage of the present invention is that 
it incorporates file servers that are the source of data to be backed up by having historical 
versions of data stored into a local site repository and a peer remote repository. Further, Whiting 
"walks" the file system looking for changed, new, modified or deleted files, whereas the present 
invention incorporates a filter driver that can, in real time, capture changes as they occur so that 
there is no need to "walk" file system. The present invention is further configured to maintain the 
history of all changes to a file over time, within the specified retention period and does not 
implement single-instance storage, contrary to Whiting. The present invention further allows a 
backup administrator to specify how many replicas of data need to be maintained in onsite and 
offsite repositories. Another advantage of the present invention is that for each share on each 
source fileserver, a protection policy is created that includes backup frequency, retention/purging 
and version management rules. Such is not present in Whiting. Further, the present invention is 
clearly advantageous over Whiting in providing efficient disaster recovery by having a backend 
collection of peer repositories distributed across multiple sites. Whiting does not appear to 
disclose a remote repository. 

Contrary to the Examiner's suggestion, Fujibayashi fails to cure the deficiencies of 
Whiting with regard to this element. As understood by Applicants, Fujibayashi discloses a 
method for remote backup. (Fujibayashi, Abstract). Fujibayashi's system includes a local host 
having a local storage device coupled to a remote host having a remote storage device. 
(Fujibayashi, para. [0019]). Fujibayashi's local storage is a primary storage device for storing 
data generated and/or used by the local host and its remote storage includes a secondary storage 
device for storing backup of primary storage device. Id. Fujibayashi's control manager engine 
performs backup of the primary storage and of the secondary storage independently using 
snapshots and forms multiple generations of snapshot backups of primary storage and second 
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storage devices over time. (Fujibayashi, para. [0020]). As such, Fujibayashi is concerned with 
simply performing backups by taking repetitive snapshots of the disk subsystem local and remote 
storages, wherein snapshots at each storage are taken independently and new snapshots replace 
older snapshots (Fujibayashi, para. [0023]). This means that loss of a disk system will result in a 
loss of all snapshots. However, Fujibayashi fails to address the problem of having storage 
location and number of replicas in each of its storage locations changing over time, which is 
solved by the present invention. It appears that Fujibayashi performs a one-time load of the 
primary and secondary storages and then performs localized snapshots of each storage. Thus, 
Fujibayashi's system is similar to the one disclosed in Whiting, whereby Fujibayashi's remote 
storage is Whiting's backup location. As such, Fujibayashi either alone or in combination with 
Whiting is not capable of changing the storage location and a number of replicas in each 
repository over time, contrary to the recitation of claim 1. 

In addition, Fujibayashi appears to be a primary disk storage system that can take "snaps" 
at two sites independently to maintain some historical versions over time, which means that a 
loss of primary storage facilities would cause loss of all such "snaps" as well. An advantage of 
the present invention is that it is configured to separate fileservers and repository nodes, where 
data is to be protected. The present invention maintains repository copies on separate disk drivers 
located on separate servers and transmits backup data continually between repositories. 

Further, one having ordinary skill in the art having the knowledge of Whiting would not 
look to Fujibayashi to solve the problem of having two or more repositories that are configured 
to store a replica of a file, wherein a storage location and a number of replicas in each repository 
can be configured to change over time, as recited in claim 1 . Whiting teaches away from 
maintaining multiple copies of files and thus, its combination with Fujibayashi would produce a 
system that includes a primary storage and a backup directory, where both storage locations 
perform independent snapshots of files located there. However, the ability to change the storage 
location and the number of replicas in each repository cannot be changed over time, contrary to 
the recitation of claim 1 . 

Further, as previously stated in Applicants' November 21, 2008 Amendment and 
Response, Whiting's system creates four types of files during backup: new, unchanged, updated, 
and modified. (Whiting, Col. 7, lines 59-65). Each time a backup set of files is migrated, 
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Whiting's solution searches for matching files for each new or updated file. (Whiting, Col. 8, 
lines 8-16). Further, during backup, Whiting creates and modifies files over network on the 
backup storage. (Whiting, Col. 7, lines 8-13), however, Whiting fails to disclose that these 
created or modified files are replicas of a single file. In contrast, Whiting stores only a single 
copy of the file. (Whiting, Col. 5, lines 8-11). Further, Whiting's backup policy is the same for 
all sets of files, i.e., the policy looks to a set of file to determine which files fall into one of the 
four categories specified above. This is different than having a protection policy uniquely 
defined for each share of data on the fileserver, as recited in claim 1 . The Examiner alleges that 
"each local machine may have a unique backup schedule configured. This backup schedule is 
part of the "protection policy". It is also noted that each user machine receives its own share of 
data on the server (see, [Whiting], 7:8-31)." (Office Action, page 20). Applicants respectfully 
disagree. Whiting fails to support Examiner's contention. It appears that Whiting includes a 
backup administrator that configures the backup system using administrator software function 
provided as part of Whiting's product. (Whiting, Col. 7, lines 19-21). The backup is then ran by a 
backup agent process for a network node that is selected by the backup administrator. (Whiting, 
Col. 7, lines 21-24). However, Whiting fails to disclose that it has a protection policy uniquely 
defined for each share of data on the fileserver, as recited in claim 1 . To the contrary, it appears 
that the administrator runs the same backup process for all nodes and as such, there is no "unique 
backup schedule configured" for each machine. Hence, Whiting fails to disclose, teach or 
suggest all elements of claim 1 . 

Zayas fails to cure the deficiencies of Whiting either alone or in combination with 
Fujibayashi. As previously stated by Applicants, Zayas relates backup data and techniques for 
speeding up backup operations. (Zayas, Col. 1, lines 9-10). When Zayas creates a volume of 
files, a Modified Files List ("MFL") is established storing a file ID and an epoch timestamp 
(identifying an important point in time for the volume) is set. (Zayas, Col. 3, lines 38-40). The 
file ID identifies a file on the volume that has been modified since it was last archived. (Zayas, 
Col. 5, lines 31-34). Zayas' epoch timestamp identifies the first epoch in which the file identified 
by file ID was modified since it was last archived. (Zayas, Col. 5, lines 38-40). Zayas further 
enumerates and orders all identified files in the MFL that were first modified before the selected 
epoch. (Zayas, Col. 7, lines 16-18). In addition to Applicants' prior arguments, one having 
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ordinary skill in the art armed with the knowledge of Whiting and Fujibayashi would not look to 
Zayas to fill the gaps created by this combination. The combination of all three references still 
fails to address having two or more repositories configured to store a replica of a file, wherein a 
storage location and a number of replicas in each repository can be configured to change over 
time as well as the filter driver capturing the snapshot at a specified time interval based on a 
backup frequency defined in a protection policy stored in the fileserver, wherein the protection 
policy uniquely defined for each share of data on the fileserver, as recited in claim 1. Zayas with 
its creation of a modified file list, adds very little to the Whiting-Fujibayashi combination. With 
the addition of Zayas, this three-reference combination has the capability of which files may 
have been modified. While this information may be used by either Whiting, Fujibayashi or both 
during backup of its files or localized snapshot creation, it fails to suggest the elements of the 
above-referenced elements of claim 1 . 

Some of the disadvantages of Zayas is that it is an end user primary storage product, 
which means that if the storage is damages, all current data and any "snapshots" will be lost. The 
present invention solves this problem by allowing recovery of data from a repository in case of 
fileserver failure. 

Thus, neither Whiting, nor Fujibayashi, nor Zayas, nor their combination disclose, teach, 
or suggest all elements of claim 1 , and claim 1 should be allowed. 

As stated in Applicants' prior responses, Belknap does not cure the deficiencies of the 
combination of Whiting and Zayas. Belknap discloses a media manager which incorporates an 
application program interface (API) for converting high-level generic commands into device- 
level commands for output to a media device. (Belknap, Abstract). Further, Belknap determines 
whether a media object is located within a multimedia data storage system by searching an index 
of media objects stored within the system. (Belknap, para. [0063]-[0064]). Belknap discloses an 
audio/video file media manager. For data directed to removable storage media, Belknap's media 
manager tracks which audio/video file was recorded on each medium (tape, optical disk, etc.). 
This is similar to a conventional backup catalog function. 

Burns relates to constraining client-side differencing and two tape accesses for delta 
restore and eliminates the use of reverse delta chains. (Burns, Section 4.2). In order to update a 
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single version in the reverse delta chain, Burns' server must store two new files, recall one old 
file, and perform both the differencing and reconstruction operations. (Burns, Section 4.2). 

However, the various combinations of Whiting, Fujibayashi, Zayas, Belknap and Burns 
fail to disclose, teach or suggest, inter alia, a fileserver configured to contain shares of data and 
to be connected with a repository, wherein two or more repositories are configured to store a 
replica of a file, wherein a storage location and a number of replicas in each repository can be 
configured to change over time; the fileserver includes: a filter driver configured to capture a 
snapshot of a set of the shares of data at a particular point in time and to maintain a list of 
modified and/or created files since a last snapshot occurred; the filter driver is configured to 
capture the snapshot at a specified time interval based on a backup frequency defined in a 
protection policy stored in the fileserver, wherein the protection policy is configured to be 
uniquely defined for each share of data on the fileserver, as recited in claim 1 . It should be noted 
that in order to show obviousness of a dependent claim, all of its elements, including the 
elements of an independent claim on which it depends, must be shown in the references. 

Applicants further submit that on page 20 of the Office Action, the Examiner provided an 
incomplete response to Applicants' arguments concerning the above combinations of Whiting, 
Fujibayashi, Zayas, Belknap and Burns. Applicants respectfully request clarification of the 
Examiner's submission. Should the next office action be made final, Applicants respectfully 
petition withdrawal of its finality due to the incompleteness of the present office action. 

Thus, the various combinations of Whiting, Fujibayashi, Zayas, Belknap, and Burns fail 
to render claim 1 obvious. As such, the rejection of claim 1 is respectfully traversed. Applicants 
respectfully request that the rejections of claim 1 are withdrawn and claim 1 is allowed. 

Claims 3-6, 17, and 19-25 are not rendered obvious by the various combinations of 
Whiting, Fujibayashi, Zayas, Belknap, and Burns for at least the reasons stated above with regard 
to claim 1. As such, the rejections of claims 3-6, 17, and 19-25 are respectfully traversed. The 
Examiner is requested to reconsider and withdraw his rejection of claims 3-6, 17, and 19-25. 

In the February 17, 2009 Office Action, the Examiner rejected claims 7-16, and 26 under 
35 U.S.C. 103(a) as being unpatentable over various combinations of U.S. Patent No. 6,847,982 
to Parker et al. (hereinafter, "Parker"), Fujibayashi, Zayas, "Deciding when to forget in the 
Elephant file system" to Santry et al. (hereinafter, "Santry"). 
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In the Office Action, the Examiner stated that Parker discloses all elements of claim 7 
except that it fails to teach "capturing a snapshot of the set of files at a particular point in time." 
(Office Action, page 1 1). It also appears that Examiner alleges that "[maintaining a list of 
modified and/or created files since last captured snapshot" is also taught by Zayas and not by 
Parker. (Office Action, page 11). The Examiner stated that Parker does not teach "wherein a 
storage location and a number of replicas of the version of the file can be configured to change 
over time (see paragraphs [0019]-[0020])", but that Fujibayashi discloses this element. (Office 
Action, page 12). The Examiner further stated that it would have been obvious to one of ordinary 
skill in the art at the time the invention was made to have modified Parker et al. by the teaching 
of "Zayas et al. 5 since Zayas et al. teaches 'insertion and removal of entries in the MFL are 
performed by the storage system. When the first of a file's data and metadata bits are turned on, 
the storage system adds the file to the MFL. In this way a file is added only once to the MFL' 
(see 7:40-45)" and by the teachings of "Fujibayashi, since Fujibayashi teaches 'by locating data 
backups remotely, a customer can survive a disaster by restoring data using backed up data 
mirrored in a remote location that was unaffected by the disaster' (see paragraph [0002])." 
(Office Action, page 12). Applicants respectfully disagree and traverse these rejections. 

Claim 7 recites, inter alia, a method for protecting data including storing a version of a 
file within a set of files on a primary disk storage system; capturing a snapshot of the set of files 
at a particular point in time based on a backup frequency defined in a protection policy; 
maintaining a list of modified and/or created files since last captured snapshot; examining the 
protection policy associated with the set of files to determine where and how to protect files 
associated with the set of files; and replicating the version of the file to two or more repositories 
specified by the protection policy, wherein the repositories include at least one of a local 
repository and a remote repository, wherein a storage location and a number of replicas of the 
version of the file can be configured to change over time; wherein the protection policy is 
configured to be uniquely defined for each set of files. 

Applicants again reiterate and reincorporate their arguments submitted on November 21, 
2008 herein by reference in their entireties. As previously stated, Applicants understand Parker 
to disclose an intelligent data inventory and asset management software system. (Parker, Col. 7, 
lines 18-23). The Parker system includes an Akashic File Clerk that maintains an inventory 
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database, which includes electronic signatures for every file on a work station and all new and 
changed files. (Parker, Col. 7, line 24-28). Parker allows a client to determine which files are 
critical and which are not critical, then Parker runs inventories to capture the files that have 
changed and forwards the changed files to an Akashic Vault for storage and processing. (Parker, 
Col. 7, lines 28-35). During inventories, Parker identifies files that have 1) changed since the last 
inventory, 2) been deleted since the last inventory, 3) been added since the last inventory. 
(Parker, Col. 8, lines 17-26). Parker's Akashic Vault is a computer that is attached as a node to 
the client's network which stores captured files. (Parker, Col. 7, lines 44-46). After capturing 
files, Parker's Vault generates reverse and forward deltas, then deletes the previous version and 
archives the newest compressed version of the file. (Parker, Col. 9, line 54 to Col. 10, line 4). 
Parker generates a list of forward delta(s) and copies of the new files and sends them to an offsite 
Library System. (Parker, Col. 10, lines 5-8). As stated in Applicants' November 21, 2008 
response, this is different than replicating the version of the file to two or more repositories 
specified by the protection policy, wherein the repositories include at least one of a local 
repository and a remote repository, wherein a storage location and a number of replicas of the 
version of the file can be configured to change over time, as recited in the amended claim 7. 

Parker discloses how files at a client system are check-summed to determine whether 
their content changes over time and only those files that are new or have changed are sent to the 
Akashic Vault. (Parker, Col. 7, lines 24-35). However, Parker's policy is not uniquely defined 
for each set of files, contrary to the recitation of the amended claim 7. 

Fujibayashi and/or Zayas fail to cure the deficiencies of Parker for at least the reasons 
stated above with regard to the combination of Whiting, Fujibayashi and Zayas. The combination 
of Parker, Fujibayashi and Zayas still fails to disclose all elements of claim 7 including, but not 
limited to, inter alia, capturing a snapshot of the set of files at a particular point in time based on 
a backup frequency defined in a protection policy and replicating the version of the file to two or 
more repositories specified by the protection policy, wherein the repositories include at least one 
of a local repository and a remote repository, wherein a storage location and a number of replicas 
of the version of the file can be configured to change over time; wherein the protection policy is 
configured to be uniquely defined for each set of files. 
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Thus, the combination of Parker, Fujibayashi and Zayas fails to realize the present 
invention. The combination of Parker, Fujibayashi and Zayas stamps specific identified files with 
a file ID and an epoch time stamp that indicates time since prior backup. The combination 
enumerates and orders the files and removes from the Modified File List. Thus, for at least the 
reasons stated above and in Applicants' November 21, 2008 response, the combination of Parker 
Fujibayashi and Zayas fails to disclose, teach or suggest the above-referenced elements of claim 
7. 

As previously stated, Santry also fails to cure the deficiencies of either Parker, 
Fujibayashi, Zayas, or their combination. Santry discloses a file system that keeps old versions of 
the file for recovery purposes (Santry, pg. Ill, section 1). Santry does not keep old versions of 
the files and only keeps a single current version. (Santry, pg. 1 13, section 3.3). However, neither 
Parker, nor Fujibayashi, nor Zayas, nor Santry nor their combination discloses, teaches or 
suggests the subject matter of claim 7. As such, the rejection of claim 7 is respectfully traversed 
and the Examiner is requested to reconsider and withdraw his rejection of claim 7. 

Claims 8-16 and 26 are patentable over various combinations of Parker, Fujibayashi, 
Zayas, and Santry for at least the reasons stated above with regard to claim 7. As such, the 
rejections of claims 8-16 and 26 are respectfully traversed. The Examiner is requested to 
reconsider and withdraw his rejections of claim 8-16 and 26. 
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CONCLUSION 

No new matter has been added. The claims currently presented are proper and definite. 
Allowance is accordingly in order and respectfully requested. However, should the Examiner 
deem that further clarification of the record is in order, we invite a telephone call to the 
Applicants' undersigned attorney to expedite further processing of the application to allowance. 

Applicants believe that no additional fees are due with the filing of this Amendment. 
However, if any additional fees are required or if any funds are due, the USPTO is authorized to 
charge or credit Deposit Account Number: 50-03 11, Customer Number: 35437, Reference 
Number: 25452-013. 

Respectfully submitted, 
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